Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add "unscoped" mode to "model config" #1348

Closed
ideomix opened this issue Oct 3, 2012 · 16 comments
Closed

add "unscoped" mode to "model config" #1348

ideomix opened this issue Oct 3, 2012 · 16 comments
Assignees
Milestone

Comments

@ideomix
Copy link

ideomix commented Oct 3, 2012

I want to add a "unscoped" mode to "model config".
I also read the entry in the past, such a way as to create a subclass is difficult to accept.
To "model config" section of the "raid_admin.rb" simple, strongly desired a solution that can be configured as "unscoped = true".

What everyone think?

@ideomix
Copy link
Author

ideomix commented Oct 3, 2012

I'm sorry in poor English.

@mikefrederick
Copy link

+1 for support for unscoped.

For example, my app has a BlogPost model and my default_scope is set such that a BlogPost must be marked as published. The only time I would want to be able to see an unpublished BlogPost is in the admin area, so it is less than ideal for me to have to remove my default_scope.

@bbenezech
Copy link
Collaborator

Can you sublass your model to add the unscoping?

Someone did this once. I wish someone would make this work reliably (routing, naming, etc.) and document it in the wiki.

The whole idea of RailsAdmin is "read my models, show me what they are and don't be smart about it".

I can't think of a nice way to include an 'unscoped' feature.

@gaaady
Copy link

gaaady commented Mar 24, 2013

+1
any update on this?

@Curter29
Copy link

Curter29 commented Aug 9, 2013

+1

@jxpx777
Copy link

jxpx777 commented Apr 2, 2014

Any update on this? Here's a particularly compelling use case:

class Product < ActiveRecord::Base
  default_scope -> { where(active: true) }
  # etc
end

Then in my view

<%= render Product.all %>

The workaround is to just not have a default scope:

class Product < ActiveRecord::Base
  scope :active, -> { where(active: true) }
  # etc
end

Then anywhere I want to show products to the user-facing app, I have to remember to call Product.active as part of the AREL chain. This is the opposite of DRY.

But in my admin view, I should be able to edit all products, regardless of whether it's active or not. I have another mechanism for controlling whether the inactive records can be read or updated. This is the power of RailsAdmin but by not unscoping the queries by default, it's hamstringing the simplicity and automatic nature of RailsAdmin.

I was surprised that this wasn't the default or at very least to see a config option for allowing it. Something like this seems perfectly reasonable:

class Product < ActiveRecord::Base
  default_scope :active, -> { where(active: true) }
  rails_admin do
    # list, etc.
    preferred_scope :unscoped
  end
end

should be sufficient. So, if config.preferred_scope is set, before doing any of the model fetching

module RailsAdmin
  module Adapters
    module ActiveRecord
      def scoped
        if config.preferred_scope
          model.send(config.preferred_scope.to_sym)
        else
          model.all
        end
      end
    end
  end
end

This would allow the individual models to scope themselves just like they're allowed to control which attributes are visible and editable. As long as the preferred_scope method returns an ActiveRecord::Relation, then the rest of the engine gets to carry on just as it has. Seems to me like a precise config option to add and conditional into the scoped method with little impact elsewhere.

@cassidyclawson
Copy link

+1

Just another vote for this feature.

@dmitrypol
Copy link

+1

@mshibuya
Copy link
Member

In fact, this can already be achieved by list scope configuration(added by #1861).

RailsAdmin.config do |config|
  config.model Player do
    list do
      scopes [:unscoped]
    end
  end
end

@mshibuya
Copy link
Member

As is stated in #2428 (comment), above solution only works for list view.
I'll try to work this out...

@mshibuya mshibuya reopened this Oct 10, 2015
@mshibuya mshibuya self-assigned this Oct 10, 2015
@dmitrypol
Copy link

When using RailsAdmin 0.7.0 with Mongoid (4 and 5) I get this error when accessing http://localhost:3000/admin/user?model_name=user&scope=unscoped

Here is my RA config:
config.model 'User' do
list do
scopes [nil, :unscoped]
end
end

gems/ruby-2.0.0-p594/gems/rails_admin-0.7.0/app/views/rails_admin/main/index.html.haml where line #154 raised:

nil can't be coerced into Float
Extracted source (around line #26):
count_without_padding = 0 if count_without_padding < 0

26 total_pages_count = (count_without_padding.to_f / limit_value).ceil
if max_pages.present? && max_pages < total_pages_count
max_pages
else

@dburt
Copy link
Contributor

dburt commented Oct 19, 2015

@mshibuya please let me know if you can use my help. For example, if my pull request is not too far off functionally, you could show me what you want the DSL to look like, and I would be happy to change my implementation and create another pull request.

@jszwedko
Copy link

Any update on this? #2586 looks compelling.

@Otterpocket
Copy link

Was this resolved somewhere else? #2586 is still not merged

@dfabreguette
Copy link

I still have the same issue with latest version of mongoid & RailsAdmin :
rails_admin (2.2.1)
mongoid (7.3.3)

"unscoped" call removes all pagination filters in the Mongoid Criteria object.
Any idea how I can fix this as we use "default_scopes" on many rails models in our app, affecting default sorts.
As a result, sorting is simply not working in rails admin because of those default scopes.

I assume the best option for us would be to feed RailsAdmin a default "MyModel.unscoped" object which gets prepared with pagination and other filters.
Has someone got the same problem ?

@mshibuya mshibuya added this to the 3.0.0 milestone Dec 4, 2021
@canted
Copy link

canted commented Jan 13, 2023

I had the same issue as @dfabreguette and resolved it using unscope instead of unscoped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests